<?xml version='1.0'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>

  <head>

    <title>SoapTrace.Net's History</title>

    <link href="../css/styles.css" rel="stylesheet" type="text/css"/>
  </head>

  <body>

    <h1>Why SoapTrace.Net?</h1>

    <p>SoapTrace.Net grew out of the need to handle some 
    misuse/abuse of soap web services on one project. Before the web 
    service misuse, tools like Microsoft's Soap Trace, PocketSoap's <a>
    TcpTrace</a> and <a>YATT</a> were used alongside good old fashioned 
    logging. Microsoft's Soap Trace was predominantly used, because it 
    gave a nice pretty print view of the soap messages. It even handled 
    the early abuse of web services where xml was sent as a string 
    parameter through the soap message, leading to &amp;lt; &amp;gt; 
    character encodings, which made viewing the raw messages either in 
    TcpTrace or a log file painful. Microsoft's Soap Trace displayed 
    the underlying xml, without the character encodings, so it became 
    the main tool for debugging issues with the web services.</p>

    <p>Then along came even more web service abuse.</p>

    <p>To reduce bandwidth certain messages had their xml strings 
    gzipped and then base64 encoded. Viewing these messages even in 
    good, old Microsoft's Soap Trace was impossible. Decoding gzipped, 
    base 64 encoding text back into its original xml using only the 
    power of the human brain was an impossible task. If only it were 
    possible to do some post processing of the messages before they 
    were displayed in the GUI, then we could transform the data back 
    into xml and debugging would become easy again.</p>

    <p>SoapTrace.Net was born.</p>

    <h1>History</h1>

    <p>In its first incarnation, developed outside of working hours, it 
    was just a proxy server that could display the raw soap messages, 
    pretty print them or decode the gzipped, base 64 encoded xml. The 
    messages were displayed in plain black and white text, and the UI 
    was similar to Microsoft's Soap Trace's, but it did not have an 
    MDI. It had a few NUnit tests too, just for good measure.</p>

    <p>As well as handling the web service abuse, limitations of 
    Microsoft's Soap Trace utility were improved upon:</p>

    <ol>

      <li>It occasionally crashes.</li>

      <li>It uses Internet Explorer to display the resulting soap 
      messages. Intermittently either IE or the soap trace application 
      gets confused and refuses to display the soap message.</li>

      <li>It cannot be customised. If for some reason you decide to 
      send gzip/base 64 encoded data through the web service you cannot 
      see what the actual data is.</li>

      <li>No source code is provided.</li>

      <li>The list view display of connections is not that useful if 
      you are just interested in seeing soap messages sent from 
      applications on your local machine. The list view displays the IP 
      address of the connecting client application.</li>

      <li>It does not handle "chunked" http data.</li>

      <li>Proxy server only.</li>

    </ol>

    <p>The next stage was to overhaul the back end, rewrite the proxy 
    server code, which I did not like, and add packet capture 
    functionality.</p>

    <p>Before this happened the project was converted from Visual 
    Studio .Net 2003 to a 
    <a href="http://www.sharpdevelop.com/OpenSource/SD/"
     title="Go to SharpDevelop's website.">SharpDevelop</a> project. 
    The main reason for this was because SharpDevelop is great free 
    .Net IDE, which is also open source, and the idea of being able to 
    tinker with the code of your development environment appealed to 
    me.</p>

    <p>The proxy server was written and WinPcap.Net was brought into 
    the world, a simple managed C++ wrapper around the WinPcap 
    library.</p>

    <p>A custom formatter plug-in architecture was added, so the 
    application was extendable without having to hack the source code. 
    How useful this feature is, outside of web service abuse, remains 
    to be seen.</p>

    <p>A SourceForge project is created for SoapTrace.Net.</p>

    <p>Windows Raw Sockets was added to the mix, for people who do not 
    want to install WinPcap.</p>

    <p>Fed up with the boring black and white text, colour was added to 
    the soap messages. First attempt involved the main form's code 
    formatting the xml text using the XmlTextReader and a rich text 
    box. This evolved into a Formatted Text class, which allowed the 
    custom formatters to colour the text being displayed in the GUI.</p>

    <p>Running some tests against <a href="http://www.codeproject.com"
     title="Go to CodeProject's website.">CodeProject's</a> web 
    services, showed that the packet capture logic, which at the time 
    was extremely dumb, needed overhauling. To help debug packet 
    issues, alongside Ethereal, the Packet Viewer dialog was added. 
    This shows the data packets that SoapTrace.Net received, allows 
    them to be saved to an xml file and reloaded back into the UI.</p>

    <p>Raw Sockets caused a bit of a headache, at least on my test 
    machine, the standard SYN, SYN-ACK, ACK packet sequence that occurs 
    on making a tcp connection, gets mixed up with raw sockets. For 
    some reason the packets arrive in the sequence SYN, ACK, SYN-ACK, 
    so we get the server's acknowledgement (SYN-ACK) of the original 
    connection attempt (SYN) after the client has already sent out the 
    acknowledgement (ACK) of the server's acknowledgement. Maybe Raw 
    Sockets uses some sort of localised time travel.</p>

    <p>All the user settings, such as form positions and layout, are 
    saved on the local machine under "C:\documents and 
    settings\username\Local Settings\Application Data\SoapTrace.Net" 
    since roaming information such as the network interface being used 
    for packet capture does not make sense.</p>

    <h2>Version 0.2</h2>

    <p>Simple logging was then added.  Each matched soap request and 
    response pair is logged to their own xml file.  If the current 
    logging implementation is not to your taste you can provide your 
    own assembly which implements the ISoapMessageLogger interface.  
    The soap message is actually stored in a CDATA section, the main 
    reason for this is so if the client or server chucks out badly 
    formed xml the log file will still be well-formed.</p>

    <p>Message replay was added, allowing the user to select a soap 
    request, edit the text and re-send it.  Currently it does not allow 
    the user to select multiple messages and replay them.  Not sure if 
    this will be implemented.</p>

    <h2>Version 0.3</h2>

    <p>After a request in the help forum, support for multiple 
    proxy servers was added.  SoapTrace.Net now supports a tabbed view, 
    each tab has its own settings, so you can set up packet capture for 
    multiple remote machines or you can run multiple proxy servers.</p>

    <h2>Version 0.4</h2>

    <p>The managed C++ WinPcap.net library was ported to C#.  It uses
    PInvoke to call unmanaged methods provided by wpcap.dll.</p>

    <p>The configuration file location no longer changes with a new
    version of SoapTrace.  The location originally depended on the
    Application.LocalUserAppDataPath which is of the form 
    "C:\Documents and Settings\[user]\Local Settings\Application 
    Data\CompanyName\ProductName\ProductVersion".  The config file
    is now stored under "C:\Documents and Settings\[user]\Local 
    Settings\Application Data\SoapTrace.net".</p>

    <h2>Version 0.5</h2>

    <p>Some small usability changes:</p>

    <ol>

      <li>Middle clicking a tab closes it.</li>

      <li>Tab right click context menu.  Menu options "Close tab" and
      "New Tab".</li>

      <li>New tab menu option now displays the settings dialog.</li>

      <li>Added an "Undo Close" menu option.  Remembers the settings for
      the last 5 closed tabs.</li>

    </ol>

    <p>Added some performance improvements so large XML files
    are displayed quicker.  It takes about 1.5 seconds to display a
    40KB soap message, down from taking 15 seconds.  This is still a bit
    slow, but further improvements will probably require me ripping out
    the RichTextBox and using a custom control.  Colouring the text in 
    a RichTextBox seems to generally be quite slow.</p>

    <p>You can now choose to show the application in the TaskBar
    Notification Area, more commonly and incorrectly known as the
    System Tray</p>

    <p>Fixed a bug where the application prevented the user from 
    logging off or shutting down.</p>

    <p>Added .NET 2.0 to the configuration's supported runtimes so 
    SoapTrace will run with just .NET 2.0 installed</p>

    <p>Can now run SoapTrace under different user accounts at the same
    time. Previously you would see an access denied error as the SoapTrace
    application tried to access another's mutex.</p>

    <p>Fixed a bug where the formatting was off if the soap message contained
    newlines instead of a newline and carriage return pair.</p>
    
    <h2>Version 0.6</h2>

    <p>SoapTrace did not work with WinPcap 3.1 since the pcap_findalldevs_ex
    method used different parameters to the one with WinPcap 3.0. The code
    has been modified to use the older pcap_findalldevs which works with
    both versions.</p>

    <h2>Version 0.7</h2>

    <p>The code has been modified to work with .NET 2.0 and can now
    be opened and compiled with Visual Studio or on the command line with
    MSBuild.</p>

  </body>

</html>

